What can context do for web services?

Academia and industry, with the rapid development of information technologies, are adopting Web services due to their integration capabilities. Web services are being actively used for connecting business processes in business-to-business scenarios. The Web services community uses different languages for specifying Web services composition like BPEL and WSFL. The primary objective of these specification languages is to provide a high-level description of the composition process independent from any implementation details or concern. The need for a common semantics is intensified when Web services participate in the same composition. Web services, to reduce the limitations, must be context-aware, context is the information which characterizes the interactions between humans, applications and the environment. A possible solution to achieving a contextual semantic composition of Web services is built upon the semantic-value concept

Moving vs. inviting software agents

Servlet and applet strategies are discussed that can enhance the operations of software agents. In the servlet strategy, the flow takes place from the client to the server and in applet strategy the flow takes place from the server to the client. The state-of-the-art in developing complex systems revolves around software agent technologies. Software agents should be embedded with mechanisms that allow them to make the correct decision: either move or invite

Cardinality heterogeneities in Web service composition: Issues and solutions

Data exchanges between Web services engaged in a composition raise several heterogeneities. In this paper, we address the problem of data cardinality heterogeneity in a composition. Firstly, we build a theoretical framework to describe different aspects of Web services that relate to data cardinality, and secondly, we solve this problem by developing a solution for cardinality mediation based on constraint logic programming

Context for Personalized Web Services

The paper discusses the way context is used for Web services personalization. A Web service is an accessible application that other applications and humans can discover and trigger to satisfy various needs such as car rental. Context is the information that characterizes the interactions between humans, applications, and the surrounding environment. Web services are personalized so that users\u27 preferences can be accommodated. Preferences are of different types varying from when the execution of a Web service should start to where the outcome of this execution should be delivered. Besides users\u27 preferences, this paper highlights that the resources on which the Web services are performed have an impact on Web services personalization

On Coordinating Personalized Web Services using COOPS

This paper presents CooPS, which is a method for Coordinating Personalized Services. These services are primarily offered to mobile users. Very little has been done so far regarding first, personalizing Web services for the benefit of mobile users and second, providing the methodological support to designers who specify the operations of personalization. Various obstacles still exist such as lack of techniques for modeling and specifying the integration of personalization into Web services, and existing approaches for Web services composition typically facilitate orchestration only, while neglecting contextual information on users and Web services

E-commerce through wireless devices

© 2001 IEEE. This paper presents the E-CWE (E-Commerce through Wireless dEvices) project. This project aims at investigating techniques and offering solutions that could support stationary and mobile users in secure wireless electronic commerce environments. In addition, the verification and demonstration of the suitability of software agents in these environments is discussed in this paper

Ontologies for specifying and reconciling contexts of web services

This paper presents an ontology-based approach for the specification (using OWL-C as a definition language) and reconciliation (using ConWeS as a mediation tool) of contexts of Web services. Web services are independent components that can be triggered and composed for the satisfaction of user needs (e.g., hotel booking). Because Web services originate from different providers, their composition faces the obstacle of the context heterogeneity featuring these Web services. An unawareness of this context heterogeneity during Web services composition and execution results in a lack of the quality and relevancy of information that permits tracking the composition, monitoring the execution, and handling exceptions. © 2006 Elsevier B.V. All rights reserved

CAiSE Workshops - Selection of web services for composition using location of provider hosts criterion

We present a Web service composition approach that relies on three selection criteria: execution cost, execution time, and location of provider hosts. A Web service is an accessible application that can be automatically discovered and invoked by other applications and humans. Web services can be composed into high level business-processes that users trigger in order to satisfy their needs. Because providers can have Web services in common, criteria are needed to select which Web services will be considered for composition. Location of provider hosts is among these criteria and aims for example at reducing the number of remote interactions between provider hosts

Towards a user-centric social approach to web services composition, execution, and monitoring

This paper discusses the intertwine of social networks of users and social networks of Web services to compose, execute, and monitor Web services. Each network provides details that permit achieving this intertwine and thus, completing the three operations. A user social-network is used to advise users on the next Web services to select based on their peers’ experiences, whereas a Web service social network is used to advise users on the substitutes to select in case a Web service fails, for example. To make the intertwine of these social networks happen, three components are developed: composer, executor, and monitor. The social composer develops composite Web services considering relations between users and the ones between Web services. The social executor assesses the impact of these relations on these compositeWeb services execution progress. Finally, the social monitor replaces failing Web services to guarantee the execution continuity of these composite Web services. A running example and a prototype illustrate and demonstrate the intertwine of these social networks, respectively.Zakaria Maamar, Noura Faci, Quan Z. Sheng and Lina Ya